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Abstract. We show how the event-based notation offered by Event-B 
may be augmented by algorithmic modelling constructs without disrupt- 
ing the refinement-based development process. 

1 Introduction 

One of the lessons of the DEPLOY project [5] is that the industrial application of 
formal modelling cannot fully succeed by employing just one notation, paradigm 
and methodology. In the case of Event-B [3] , one of the language strong sides at 
the level of abstract design - a simple and versatile notation suitable for a wide 
range of abstractions - makes the language difficult to apply to concrete designs. 
Unstructured event-based models often become unwieldy long and verbose when 
design and implementation decisions are added. 

In this paper we discuss a proposal to extend the event-based notation of 
Event-B with algorithmic constructs that permit an efficient specification of a 
large class of concrete designs. 

Our extension, language SLP (sequential composition, loop, parallel compo- 
sition), is a compact formal modelling notation with strictly defined syntax and 
semantics. To stay on the same technological platform as Event-B, we define the 
language semantics as a list of FOL verification conditions. We adopt without 
changes the mathematical language of Event-B - the part of the notation used 
to define predicates and expressions. The languages also borrows the notation 
and the atomicity assumption of Event-B substitutions. 

Rather than a replacement or a simple superposition of algorithmic and event 
styles we propose to have a seamless connection between Event-B and SLP where 
a high-level event specification is gradually transformed into an algorithmic spec- 
ification with explicit concurrency and control flow (see Fig. [1]). 

The defining difference between SLP and Event-B is that the latter is data- 
driven while the former features explicit control flow for sequential computation 
and units of concurrency for concurrent computations. This requires a departure 
from a flat machine structure, apt for inductive reasoning but often onerous in 
practice for large models, to a hierarchical model with nested naming scopes 
delineating verification concerns. 



2 Syntax 



An SLP model is made of the following three main parts. The first, taken ver- 
batim from Event-B, provides definitions of types, axiom, variables, invariants 
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Fig. 1. The SLP approach promotes a gradual transition from an event-based 
to an algorithmic specification. 



and theorems. This part may also contain Event-B events in the case of a mixed 
Evcnt-B/SLP model. 

The second part is the definition of environment activities. In SLP, we take 
a view that actions performed by an environment must be explicitly defined as 
such. This is not just a syntactic notion - SLP offers differing refinement rules 
(not discussed in this paper) for environment and system activities. 

The final part is the definition of the behaviour of a modelled system. It takes 
the form of a list of so-called process definitions - concurrent units of system 
behaviour. The body of a process is defined by a succession of atomic state 
updates (substitutions, in the Event-B terminology) connected by the typical 
algorithmic control structures - sequential composition, if and loop. A process 
body runs in an infinite loop until it explicitly executes a termination command. 

The processes of a system and environment activities execute concurrently. 
They interact by reading and writing shared (global) variables. A system process 
may also define its private (local) variables to deal with computations that do 
not need to be exposed to environment or other system processes. For a given 
process, the universe of the process is the set of all other processes and all the 
environments. 

The following is the top-level structure of an SLP specification: 

sip := (invdef)* 

(environment) * 
(process) + ; 

(invdef) := (invariant | theorem) (label) : (predicate) ; 

To simplify the presentation, we omit the declaration of constants and sets while 
variable declarations are deduced from invariants. All the variables defined at 
the global level are seen by system and environment processes. These should be 
the variables used to model input/output between the environment and system 
components. Like in Event-B, we split invariant conditions to label and partition 
invariant preservation conditions. 

An environment is a labelled pair of a rely and guarantee predicates. Like 
invariants, rely and guarantees are labelled. 



1 Note that this is our preferred concrete syntax. The abstract syntax for these ele- 
ments is exactly that of Event-B 



{environment) := environment {label) (reldef)' {gardef) end; 
(reldef) := rely {label) : {predicate) ; 
{gardef) := guar {label) : {predicate) ; 

The following is an example of an environment describing the behaviour of 
a temperature sensor. The environment may update value of t (current temper- 
ature) by changing it in some small increments defined by constant A. A rely 
predicate is omitted and assumed to be T. 

environment temp_sensor 

guar guarl is i' £ t - A .. t + A 

end 

A system activity, called a process, follows the template of an environment 
but may also define local variables and concrete behaviour specification. 

{process) := process {label) {reldef)* {gardef)* (invdef) {block)? end; 

Informally, the body of a process is the implementation that is shown to tolerate 
the interference defined by the process rely and satisfy the obligation of the 
process guarantee. In an extreme case of a solipsistic process there may be no 
rely and guarantee predicates so that the process has no specific obligations to its 
universe. Such a process specifies a sequential algorithm that runs till completion 
without any interaction. 

Continuing the theme of the sensor example, with the syntax discussed, we 
can already define a small but meaningful specification. The temperature sensor 
t belongs to the environment while the system controls the heater modelled by 
variable heater: 

invariant temp : t £ Z 
invariant heater : h £ BOOL 
environment tcmpjsensor : 

guar guarl is i' € t - A .. t + A 

end 

process heater_control 

rely rell : t £ SAFE.TEMP 

guar guarl : t > TEMP .HIGH A h = TRUE => ti = FALSE 
guar guar2 : t < TEMPJLOW A h = FALSE ti = TRUE 

end 

There may be any number of environment and process parts. One may, for 
instance, add an alarm process to detect an abnormal temperature range. 

invariant alarm : alarm £ BOOL 
process alarm_control 

guar guarl : alarm' = bool(t g SAFE.TEMP) 

end 



Note that the rely of heater_control is not always satisfied by the sensor be- 
haviour. A system process is temporarily disabled if its rely is broken by an 
environment. A process, however, may not violate the rely of another process or 
an environment. 

The body of a process describes how the activity defined by its guarantee 
predicate is realised. The following operators are used to build the body of a 
process: 



(block) 
(action) 
(statement) 
(if) 



(loop) 



(begin-end) 
(assert) 



(action) ; (block) ; 

(statement) atomic? (refines)! (with)? 
(substitution) \ (if) \ (loop) \ (begin_end) 
if (predicate) then (block) 
(elseif (predicate) then (block))* 
(else (block))? end ; 
while (predicate) 
(invdef) ' 

var (expression) 

then (block) end ; 

begin (invdef)* (block) end ; 

(assert ((label) :)? (predicate) y 



(assert) | stop 



Most of the syntax is self explanatory. The stop statement terminates a process; 
assert p asserts the truth of p; (substitution) and (expression) are Event-B 
substitution and expression elements (see Rodin Deliverable D7 [7] for concrete 
definitions). Block begin_end defines the scope of visibility for local variables. 
Elements atomic, (refines) and (with) are used to define the refinement rela- 
tionship between SLP models but are not discussed in this paper. 

A trivial implementation of heater_control retells the implications in the pro- 
cess guarantee as an if statement: 



process heater_control 

rely rell : t G SAFE.TEMP 

guar guarl : t > TEMPJ3IGH + S A h = TRUE =>ti = FALSE 
guar guar2 : t < TEMPJLOW — 5 Ah = FALSE => ti = TRUE 
if t > TEMPJRGH + S A h = TRUE then 

actl : h! : = FALSE 
elseif t < TEMP.LOW — 6 Ah = FALSE then 

act2 : h! : — TRUE 

end 

end 



2.1 Semantics 

Similar to Event-B, the semantics of SLP is given as a list of verification condi- 
tions called proof obligations. We discuss only the consistency conditions showing 



that the SLP part of an Even-B/SLP model does not violate invariants and in- 
troduce deadlocks and divergences. Informally, the purpose of consistency proof 
obligations is to establish the following three facts: 

— when control is passed to a statement, the state update defined by the state- 
ment may take place; 

— any statement docs not take the system outside of the safety invariant 
bounds; 

— a statement eventually terminates. 

Wc begin by cataloguing the major syntactic elements of a specification. 
The following are coming from Event-B and are shared between Event-B and 
SLP models: constants c, carrier sets s, axioms P(c, s), global variables v and 
invariant I(c, s, v). 

There are elements specific to SLP. Taking the viewpoint of a substitution S 
located somewhere in the body of a process, they are: the rely R(c, s, v, v') and 
guarantee G(c, s, v, v') of a current process; process variables u (must be distinct 
from w); process invariant T(c, s,v,u); variables defined in enclosing begin... 
and while . . . blocks, w = {u>i, . . . , Wi} (all distinct); begin . . . and while . . . 
block invariants Bi(c, s, v, u, Wi, . . . , Wi); assertion predicate A[c, s, v, u, w) ex- 
pressed directly in a preceding assert or derived from other kind of a preceding 
statement; and, finally, the substitution itself - S(c, s, v, u, w, v', u', w'). 

The following shorthand is used to identify syntactic element in the context of 
substitution S. Assume that S is contained inside i nested blocks begin/while 
that define some local variables u and w. In the scope of S(. . . ) the actual 
invariant is 2^, as defined below. The invariant defines the state space fli on 
which the update defined by S takes the effect: {z \ S(z)} C fij x Oj. 



(P(c,s) \ 
I(c,s,v) 
T(c, s, v, u) 

\ Aj<i Bj( c j S,V,U,Wi, . . . ,Wj) J 



A = A{c, s, v, u, w) 

S = S(c, s, v, u, w, v', u', w') 

fli = {z\ li(z)} 



Extended state fli adds a termination symbol y/ from which no continua- 

tion is possible. Globally, the set of all names spaces forms a tree such that the 
state of an inner wholly contains the state of outer space: Cj C • • • C £l n 
where fio is the state of a name space of containing just global variables and £l n 
is the state of some current block within the body of a process. 

To define verification conditions, we convert SLP statements into relations 
describing the connection between previous and next states. All the partial state 
update relations are treated as guarded relations (i.e., never applied outside of 
their domain) and loops are required to terminate to ensure total correctness. 
We write II meaning [Zj], I meaning [I], A for [A] and so on. 



[stop 
[assert p 
assert p ; b 

[a ; b 
si||...||s„ 
u := E{v) 
[u :G E{v) 
\u:\E{v,v') 
if Co then bo 
elseif cithen b\ 

elseif Cfcthen bu 
else b e end 
while c 
invariant LI 
var V 
then b end 
begin 

invariant BI 

b 

end 



id(b]nOi) 

{mHu' u' G Eiv)}* 
{u^u'\ E(v,v')} 

((c < 6 ) U (ci < 61) U ■ • • U (c fc < b e )Y 
where c 4 = a \ (U f £ o..i-i c i) 



assert A LI A trm ( C, LI, V", 



U+i 



= ([bj]< [6] n(nixni) 



Operator r° extends a relation r C Qj x f2j/ to a total relation r' C f2j f2 



w 



so that mappings not covered by r are taken from id(0,): 



{a; n- y \ x n- 



j/GrVxM>yG id(Oj) \ r} = id(fij) <3- r. Also, as a shorthand, for some 
predicate x G f2j — ?>BOOL we write [x] to mean a set of elements satisfying x: 
[x] = {e I x(e)}. 

In the definition of a loop, V E Hi — >N is a loop variant and trm is a ter- 
mination condition expressing that the variant value is decreased by each loop 
iteration: trm(C, LI, V, b) = Vx,y ■ x G V [b[st]] A y G V [st] =>■ x < y, where 
st= In [XiAc]. 

Note the two rules for sequential composition. The a ; b case defines the 
conventional sequencc-to-rclational-join rule. The preceding rule (of a higher 
precedence) makes the sequential composition 'forgetful' when an assertion is 
placed between two statements: the information about previous statements is 
dropped and the focus is placed on the last statement and the preceding asser- 
tion. One reason for this is that a chain of substitutions may lead to a large 
and intractable set of hypothesis preventing efficient automated proof and in- 
troduce an undesirable interdependency between substitutions where a change 
in one substitution could invalidate proofs done for successive substitutions. An 
assertion breaks such a chain making the proof context smaller. Another reason, 
specific to our technique of refining Event-B into SLP, is the use of assertions 



to prove that the set of enabling states of a refined substitution does not grow 
larger in a refined model. 

The following is a list of the more important proof obligation, given, for 
brevity, in a relational form. 

Well-definedness SLP mirrors the Event-B approach of proving that each partial 
relation is well-guarded. In other words, we prove that a relation defined by 
statement a may be applied to a current state: (II n A) < [a] ^ 0. 

Feasibility of rely The rely must not contradict an invariant: I < R C I x I. 

Closure of rely Conditions involving rely invariably require tolerating any num- 
ber of rely iterations. To simplify corresponding proof obligations we insists that 
a rely relation R is reflexively and transitively closed: id(fif) CRARoRCR. 

Invariant preservation Invariant properties of model variables are assumed to 
hold before every substitution. It must be proven that all invariants known in the 
scope of a substitution are re-established by the substitution: [a] [II n A] C II. 
Not that when statement a is located in the body of a loop II also includes the 
loop invariant. 

Variant A loop variant is based on the same principles as Event-B variant and 
is embedded into the rule converting a loop into a relational form. 

Establishing guarantee A substitution executed by a process must agree with a 
process guarantee. Formally, any state update would be covered by a 'promise' 
expressed in the guarantee: (II fl A) < [a] C G. 

Establishing assertion An asserted condition A n must be implied by a previous 
assertion or a statement. We must take into the account the fact that between 
previous and current statements the universe might have changed its state. For 
this, the latest locally known state is 'blurred' by the rely condition of a process. 

— if two assertions follow each other then the second must be contained in the 
first: (A< R) [II] C A„; 

— otherwise, if an assertion is preceded by a substitution, the preceding sub- 
stitution after-state must imply the assertion: (Ro [a]) [II] C A„; 

— otherwise, an assertion must be established by an invariant: R[ll] C A n . 

Process compatibility All non-environment processes must be compatible w.r.t. 
their rely/guarantee conditions: I<]GaC R b . 



3 From Event-B to SLP 



SLP is not a standalone formalism and is meant to complement the Event- 
B notation when one needs to obtain a detailed design expressed in terms of 
parallel processes and algorithmic constructs. Thus, there is always a stage when 
a pure Event-B specification undergoes a transformation into an Evcnt-B/SLP 
specification. 

One simple case of Event-B to Event-B/SLP refinement is introducing en- 
vironments and processes operating on new variables. In a general case, the 
Event-B part is refined to make use of new variables so that there is an informa- 
tion flow between the two parts. Naturally, there are no specific proof obligations 
for this case: one only needs to discharge the consistency conditions. 

A more interesting situation is the replacement of Event-B events with SLP 
constructs. Of all possibilities, we shall only consider the simplest one: refinement 
of a set of events by new (rather than existing) environments and processes. 

New environment (process) A new SLP environment (process) may be defined 
to refine one or more abstract Event-B events; refined events disappear from a 
model. The relevant proof obligation is that a process guarantee is contained in 
the behaviour of refined events: (I n R) < G C {ei]n, n • • • n [e n ]n. 

New concrete process A sub-set of machine events may be refined into a process 
with a body. We focus on a simpler case when this is done in a single refinement 
step. Without loss of generality, we consider the case of refinement where substi- 
tutions of a process body coincide exactly with substitutions of refined events, 
in other words, a refinement that forms a process from events without any fur- 
ther behavioural or data refinement that may take place in following refinement 
steps. 

Let E be the set of events of machine M describing the behaviour of a 
prospective process P and tr(M) \ E be the machine traces limited to events E. 
Let tr(P) be a set of traces of a new process in terms where each trace element 
is the list of labels of parallel substitution parts. It is easy to define a mapping / 
from the alphabet of tr(P) to set E (it is not necessarily a one-to-one mapping 
but this does not pose problems). If one can prove that f(tr(P)) C tr(M) \ E 
and, separately, that process P does not introduce new divergences then process 
P is declared to refine events E. We have previously shown how to convert a 
statement of the form f(tr(P)) C tr(M) \ E into a list of FOL theorems [513] . 

4 Small Example 

We illustrate the Event-B/SLP hybrid modelling by showing a simple case of 
Event-B to SLP refinement. The model computes the greatest common devisor 
(GCD) of two numbers. Function gcd €E N x N — > N axiomatically satisfies the 
following properties: 



axml : Va, b ■ a, 6eNAa>6=> gcd(a, b) = gcd(a — b, b) 
axm2 : Va, b ■ a, 6eNAo>a=> gcd(a, 6) = gcd(a, b — a) 
axm3 : Va ■ a £ N ^> gcd(a, a) = a 



At an abstract level, one may use the constant function gcd to compute the 
result in one step: 

machine gcdO 

variables r,xl,x2 

invariant r £ NAil £ NAi2 £ N 

initialisation r :G N || xl :€ N || x2 :€ N 

events 

gcd = begin r := gcd(xl i-> x2) end 

end 

Variables xl and x2 serve as input values and r holds the result. The following is 
a typical Evcnt-B refinement based on the unfolding of an atomic abstract step 
into a sequence of concrete computations. 

refinement gcd la 
refines gcdO 

variables r, xl, x2, yl, y2,pc 
invariant 

yl G N Ay2 G N 

pc G 1 . . 5 

pc = 2 => gcd(a-l t-s- x-2) = gcd(yl M> x2) A yl > A x2 > 
pc = 3 =>• gcd(sl (->■ x2) = gcd(yl H> j/2) A yl > A y2 > 
pc = 4 =>■ gcd(a;l n- x2) = gcd(yl i—¥ y2) A yl > A y2 > 

initialisation ... || yl :€ N || y2 :€ N || pc := 1 

events 

copyl = when pc = 1 then yl := xl \\ pc := 2 end 
copy2 = when pc = 2 then y2 := x2 \\ pc := 3 end 

subl = when yl > y2 Ape G {3,4} then yl := yl — y2 || pc := 4 end 
sub2 = when y2 > yl Ape G {3,4} then y2 := y2 — yl || pc := 4 end 
gcd = when yl = y2 Ape = 4 then r :— yl end 

end 

Events subl and sub2 form the body of a loop. An auxiliary variable pc is used 
to simulate control flow; variables xl,x2,yl,y2 are introduced to describe the 
concrete computation steps. Note how the after state of each event is encoded in 
model invariant. The repeating template v = C=^. . . in invariants is an indicator 
that an event-based specification is used to simulate concrete control flow. 

The SLP version of the same refinement step is given below. Here we have an 
explicit loop construct containing a two-branch if that makes for a more concise 
specification without the need to propagate state properties via an invariant. 



refinement gcdlb 
refines gcdO 
variables r,xl,x2,yl,y2 
invariant yleNAy2eN 
initialisation ... || yl :€ N || yl :€ N 
process mam 

yl := xl || j/2 := x2 ; 

while yl j/2 then 

invariant gcd(xl M> x2) = gcd(yl M> y2) A yl > A y2 > 
if yl > y2 then yl := yl — y2 
elseif y2 > yl then y2 := y2 — yl end 
end ; 
r := yl 
end 
end 

Essential to the proof of refinement is the last case of sequential composition 
where control is passed from a loop to an assignment saving the final result. The 
relational interpretation of the loop asserts the loop invariant and the negation 
of the loop condition which immediately give that r = yl = gcd(x\ i— > x2). 

5 Conclusion 

The implementation language of B-Method, BO [T] is one of the inspirations for 
this works. There are, however, important differences in both aims and tech- 
niques employed: BO allows a modeller to write more detailed bodies of abstract 
operations using the concepts from programming languages. In contrast, in SLP, 
the main development technique is an aggregation of several abstract events into 
a body of a process. This means that a data-driven design of Event-B may be 
refined into an algorithmic design whereas in BO it would have to remain data- 
driven at the top level. Equally important is an explicit treatment of concurrency 
that becomes more and more relevant topic in embedded systems design. We 
use rely /guarantee [S] approach to model cooperation of concurrent processes 
via shared variables. 

Evcnt-B is rather obviously lacking in means of control flow specification. 
One solution is the integration of two narrowly specialised two notation, i.e., 
CSP||B that combines B and CSP j5J. Another is extension of the basic notation 
with means to explicitly define control flow, i.e., the Flow plug-in for Rodin [3J. 
In this paper we followed a different direction with a premise that a deficiency of 
a notation in a certain area is best rectified by coming up with a new notation. 

This leads us to the following crucial point: to make Event-B applicable 
in any given problem domain it may be necessary to (1) design a specialised 
concrete syntax exposing Event-B method in a way tailored to the problem 
domain (for example, a graphical notation like the one offered by UML-B [5]) 
and (2) devise a specialised notation and refinement rules for concrete designs, 
like the one shown in this paper. The use of Event-B for an abstract design 
puts a development on a solid and well-studied platform. But concrete designs 
incorporating implementation decision must offer the concepts, terminology and 



structuring principles already employed and recognised in the target problem 
domain. In this sense, the language defined in this paper is merely a technological 
demonstration that such a direction is viable. 
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